The resource reservation protocol (RSVP) is a network-control protocol that enables Internet applications to request and obtain from the network differing qualities of service (QoS) for their data flows. Some applications have different network performance requirements and thus desire different QoS. RSVP is not a routing protocol but rather works in conjunction with routing protocols to install the equivalent of dynamic reservations along the routes that the routing protocols calculate. However, not every internet device (e.g., router, server) along a route may be RSVP capable.
In RSVP, a data flow is a sequence of datagrams that have the same source, destination, and QoS requirements. The QoS requirements are communicated in RSVP through a network using a flow specification. A flow specification is a data structure that describes the level of service required for a flow. The levels of service may include, for example, delivery with reasonable delay and loss (controlled load service) or delivery with guaranteed delay bounds (guaranteed service), and so on. Thus, RSVP is seen to be a network layer protocol that enables a network to provide differentiated levels of service to specific flows of data.
RSVP authentication relies on a security hash that is included in an RSVP message. The security hash facilitates neighbor authentication and replay protection. The goal of the RSVP security hash is to block unauthorized internet devices (e.g., router, host) from taking undesirable actions. The undesired actions may include, for example, injecting an unauthorized RSVP message, modifying an RSVP message in an unauthorized way, and so on. To use a security hash, an RSVP enabled device (e.g., server) needs a key. These keys need to be distributed. Conventional key distribution methods include manual distribution, a pair-wise key management protocol, and so on. Manual distribution may become burdensome if keys are changed frequently and/or if the set of devices to which keys are to be distributed is large. A pair-wise key management protocol may not be appropriate due to complexity and/or operational burden. Thus, issues associated with conventional key distribution methods may reduce the likelihood that RSVP authentication and security are employed.
RSVP uses a hop-by-hop model where, by design, a hop may process and modify the contents of an RSVP message. A hop may also perform local admission control and resource reservation. However, the “per-neighbor” key approach for RSVP authentication and security does not work when there may be an IP (internet protocol) hop between two RSVP neighbors. For example, if an end-to-end route includes both RSVP-capable and non-RSVP-capable routers, the per-neighbor key approach will not work because for some RSVP messages (e.g., Path), an RSVP device does not have information about the next RSVP hop for the message at the time the message is to be forwarded. In another example, an end-to-end route may include an RSVP device that is not configured and/or intended to be involved in RSVP security. The next RSVP hop may not be known by an RSVP device at the time of forwarding some RSVP messages because the purpose of such messages may be to discover the next RSVP hop, to dynamically rediscover the next RSVP hop after a routing change, and so on. If an RSVP device does not know the next RSVP hop for an RSVP message, then the RSVP device may not know which security association to employ when forwarding the RSVP message and in turn which per-neighbor key to use.